RBIProxy Private CA Requirements
Document Purpose
Used for HTTPS proxy (MITM) signing of RBIProxyPrivate CADefines the technical requirements of __PH_0__.
This document isCustomer Company PKI ManagerRefer to when issuing and delivering CA.
| item | Content |
|---|---|
| Applicable Products | RBIProxy (Kubernetes Deployment) |
| Follow-up Document | 02. RBIProxy 사설 CA 적용 엔지니어 가이드 |
📌 Summary — Please make sure to check
- Key Algorithm: Current release isRSA above 2048bitThis is mandatory. Since other algorithms like ECDSA do not guarantee operation, please use RSA.
- Key Format: PKCS#8 PEM Plain TextRequired (
-----BEGIN PRIVATE KEY-----).- Recommended Method: The simplest**"Dedicated Self-Signed Root CA 1"**The method is recommended. The Intermediate CA method is also possible, but please be sure to check the chain transmission constraints in section 4.5.
- Limited Use of this CA: Issue the HTTPS proxy signature exclusively for RBIProxy, and it is necessary to operate separately from the existing PKI business CA (code signing, email, etc.).
1. Overview
1.1 Background
RBIProxy intercepts the user's HTTPS traffic.Relay (MITM)Therefore, it is delivered through the Remote Browser Isolation (RBI) service.
In this process, RBIProxy is the destination domain (e.g:www.example.com) ofDynamically Reissuing Server Certificatesto provide to the user's browser, to be used as the signer (Issuer) when reissuingCA certificate/private key pair 1 setI need this.
Without using the default CA (included in the product)Utilizing the customer's own PKIIf you wish to proceed, you must prepare a CA that meets the requirements of this document.
1.2 When the application of a self-signed CA is being considered
If any of the following apply, you need to apply your own CA.
- If you want to remove browser warnings related to the use of the default CA
- Separation of certificates by customer is necessary due to internal security policy.
- If integration management with the existing internal PKI system is required
- Cases where the use of unique CA is required for audit responses in the financial sector and public sector.
💡 In the PoC or simple testing phase, you can use the provided CA as is without any additional work.
1.3 Operation Structure (Summary)
- User PC accessing external sites (e.g:
https://www.example.com) requests HTTPS access. - RBIProxy receives a request,Instant issuance of the server certificate for the domain with a private CAand delivers it to the user's browser.
- The user's browser trusts the private Root CA, so the chain validation passes.without warningIt will be processed normally.
- RBIProxy relays traffic to actual external sites.
※ For this flow to work, on the user PCPrivate Root CA is a trusted root certification authoritymust be pre-registered (distribution through AD GPO, etc.).
1.4 Overall Process
| step | subject |
|---|---|
| 1. Review of this document and decision on CA issuance method | PKI Manager |
| 2. CA Certificate/Private Key Issuance | PKI Manager |
| 3. User PC Root CA Deployment (GPO, etc.) | IT Manager |
| 4. File Transfer Through Secure Channel | PKI Manager → Implementation Manager |
| 5. Reflecting in RBIProxy | Construction Manager |
| 6. Operation Verification | Joint Cooperation |
ℹ️ "Construction Manager"refers to the person in charge who works directly in the Kubernetes environment operating the RBIProxy. Depending on the setup, it can be an in-house IT infrastructure manager, a contracted SI engineer, or a product supplier engineer. It is used with the same meaning throughout this document."
2. Prerequisites
2.1 Required Environment
| division | Requirements |
|---|---|
| Private Root CA | In-house Root CA (or internal PKI) is already in operation |
| User PC Distribution System | A private Root CA is deployed as a "Trusted Root Certification Authority" on all target PCs (e.g., AD GPO). |
| Deployment Method | Windows System Certificate Store Based (Referencing Edge/Chrome/IE) |
2.2 Scope of Effect
| Browser/Client | support | Note |
|---|---|---|
| Microsoft Edge | ✅ | Using the Windows System Certificate Store |
| Google Chrome | ✅ | Using the Windows System Certificate Store |
| Internet Explorer | ✅ | Using the Windows System Certificate Store |
| Firefox | ⚠️ Separate settings | with GPOsecurity.enterprise_roots.enabled = trueor registered in its own TrustStore |
| Java/.NET and other applications | ⚠️ Separate response | Separate registration is required in the TrustStore of each runtime. |
| macOS / Linux terminal | ⚠️ Separate response | Registration of Root CA in each OS certificate store is required |
3. Files to Deliver (Deliverables)
The following filesSecure Transmission ChannelPlease pass it on to the construction manager.
| # | file | Required/Optional | format | Description |
|---|---|---|---|---|
| 1 | CA certificate(Self-Signed Root or Intermediate) | Required | PEM (.crt / .pem) | CA to be used for signing by RBIProxy |
| 2 | CA private key | Required | PKCS#8 PEM Plain Text (.key / .pem) | The corresponding Private Key of the above certificate |
| 3 | Intermediate Chain (Intermediate CAs) | Conditional (Intermediate Method) | PEM bundle | Include all intermediate CAs between the Root and the issuing CA (excluding the Root) |
| 4 | Root CA Public Certificate | Required | PEM | Verification. If it's a Self-Signed Root method, the same file as #1 is also acceptable. |
3.1 Delivery Format Example
Option A: Separate File (Recommended)
customer-ca.crt ← #1 (single or #1+#3 chain bundle)
customer-ca.key ← #2 (PKCS#8 plaintext)
customer-root-ca.crt ← #4 (for verification)
Option B: Integrated PEM
customer-ca-bundle.pem ← #1 + #2 + #3 all included
customer-root-ca.crt ← #4 (for verification)
Option C: PKCS#12 (.pfx)
customer-ca.pfx ← #1 + #2 + #3 integration (encrypted)
* The password will be sent via a separate channel
customer-root-ca.crt ← #4 (for verification)
ℹ️ RBIProxy runtime isLoad PEM format directlyIf received in PKCS#12 format, the person in charge of the setup will convert it to PEM (cert + key) using OpenSSL and reflect it. During the conversion process, the private key will be temporarily stored in plaintext, so for security reasons**Option A (Separate File)**is needed.
3.2 Secure Transmission Channel (Recommended)
Files containing private keys must be included in one of the following:one or more methodsPlease deliver it.
| Method | Recommended Level | Note |
|---|---|---|
| PKCS#12 + Password Separate Channel Delivery | ⭐⭐⭐ | File is email, password is wired/SMS |
| In-house File Encryption Solution | ⭐⭐⭐ | If you have it |
| Encrypted USB + In-person Delivery | ⭐⭐ | When offline delivery is possible |
| S/MIME Encrypted Email | ⭐⭐ | Mutual certificate exchange required |
| General Email Attachment (Plain Text) | ❌ | prohibition |
📌 After delivery**Immediately destroy the plain text file for delivery from the client side.**Please do it.
3.3 Key Format Precautions
The Private Key must meet all of the following conditions.
| item | Required Items |
|---|---|
| Wrapping Format | PKCS#8 PEM (-----BEGIN PRIVATE KEY-----) |
| Key Algorithm | RSA above 2048bit(RSA 3072/4096 available) |
| Encryption Status | plain text(Protected in the delivery channel) |
PKCS#8 Example (Recommended)
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...
-----END PRIVATE KEY-----
PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) if you hold — conversion required
openssl pkcs8 -topk8 -nocrypt \
-in customer-ca-pkcs1.key \
-out customer-ca-pkcs8.key
Encrypted PEM(-----BEGIN ENCRYPTED PRIVATE KEY-----) if you have — Decryption required
openssl pkcs8 -in customer-ca-encrypted.key -out customer-ca-plain.key
# 패스워드 입력 후 평문 PKCS#8로 저장됨
⚠️ The converted/decrypted plaintext private key file isSecure Transmission ChannelPlease refer to section (3.2) and, after the transmission is complete, immediately dispose of the original file.
4. CA Certificate Mandatory Requirements (X.509 Extensions)
CA certificates must meet all of the following requirements. It is not recommended to reuse a CA that has been issued for other purposes (code signing, email protection, etc.), and**"CA for issuing TLS server certificates"**You need to issue a new one. (Self-Signed Root / Intermediate all have the same requirements)
4.1 X.509 Extension Field Requirements
| Extended Field | Required value | Note |
|---|---|---|
| Basic Constraints | CA:TRUE | Required— Specify that it is a CA certificate |
| Key Usage | keyCertSign, cRLSign | Required— Some browsers trigger a warning if not configured |
| Extended Key Usage (EKU) | serverAuthincluded | Required— Specify the purpose of issuing TLS server certificates |
| Name Constraints | Unconfigured required | Only the specified domain can be relayed when configured. |
| Path Length Constraint | pathlen >= 0 | end-entity issuance possible |
ℹ️ Key Usage / Extended Key Usageis increasingly being validated more strictly in the latest browsers (especially Chrome-based ones). If you set it explicitly, it is safe in terms of compatibility.
4.2 Key/Algorithm Requirements
| item | Required Items |
|---|---|
| Key Type | RSA above 2048bit(3072 / 4096 available) |
| Signature Algorithm | SHA-256 or higher(SHA-1 not allowed) |
| Expiration Date | More than 3 years needed |
ℹ️ Other algorithms such as ECDSAis not guaranteed to work in the current release, soRSA usage is mandatoryis.
4.3 OpenSSL Self Check (Before Delivery)
You can check the fulfillment of requirements with the command below before transmission.
openssl x509 -in customer-ca.crt -noout -text
Check the following items in the output:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
4.4 Chain Verification
openssl verify -CAfile customer-root-ca.crt customer-ca.crt
# 출력: customer-ca.crt: OK
4.5 Intermediate CA Operation Chain Transfer Constraints
⚠️ This section isConstraints You Must Know When Operating with Intermediate CA Methodis. If you have chosen the Self-Signed Root CA method in Chapter 1, not applicable.
phenomenon
Currently, RBIProxy is for the user's browser.Dynamically issued leaf certificatebut sends to the upper stepYou may not send the Intermediate CA together..
impact
User PC에Only Root CAIf it is installed, the browser isleaf → (빠진 Intermediate) → RootUnable to complete the chainNET::ERR_CERT_AUTHORITY_INVALIDYou can display warnings such as this.
Solution — Choose either A or B below
A. (Recommended) Use Dedicated Self-Signed Root CA
- Since the chain length is 1 (Root → leaf), there is no intermediate stage → This constraint does not apply.
- separated from the existing PKI**"RBIProxy Dedicated Root CA 1"**to issue and deliver a new
- Only the corresponding Root CA is distributed to the Trusted Root on the user's PC.
B. If you adhere to the Intermediate CA method
- User PC에Must be deployed to Intermediate CA
- Windows: "Intermediate Certification Authorities" Deploy Intermediate CA to Repository
- GPO deployment and Root CA deployment andTogether with the same policyinclude needed
- If it is an Intermediate chain of 2 or more levelsAll Intermediate StepsDeployment
Judgment Matrix
| Types of CA Received | Certificate to be distributed to user PCs | Browser Behavior |
|---|---|---|
| Dedicated Self-Signed Root CA | Only Root CA | ✅ Normal |
| Intermediate CA (Level 1) | Root CA + Intermediate CA | ✅ Normal |
| Intermediate CA (Level 1) | Only Root CA | ❌ Warning may occur |
| Intermediate CA (Level 2 or higher) | Root CA + All intermediate CAs | ✅ Normal |
4.6 Key Format Check
head -1 customer-ca.key
# "-----BEGIN PRIVATE KEY-----" ← PKCS#8 (필수)
# "-----BEGIN RSA PRIVATE KEY-----" ← PKCS#1 (변환 필수)
# "-----BEGIN ENCRYPTED PRIVATE KEY-----" ← 암호화됨 (복호화 필수)
Check Key Algorithm
openssl pkey -in customer-ca.key -noout -text | head -2
# "RSA Private-Key: (2048 bit, 2 primes)" ← 필수
# "ED25519 Private-Key:" 또는 EC 표시 → RSA로 재발급 필요
5. User PC Environment Requirements
5.1 Root CA Distribution Status Check (Windows)
# PowerShell (관리자 권한)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*<사내 CA명>*" }
or GUI:certlm.msc → Trusted Root Certification Authorities > CertificatesCheck for the existence of a private Root CA.
5.2 Additional Settings When Using Firefox (Optional)
Firefox uses its own TrustStore by default. To trust the Windows system store, use GPO orpolicies.jsonto deploy the following settings:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
orabout:config → security.enterprise_roots.enabled = true
5.3 macOS / Linux Terminal Support
| OS | Root CA Deployment Method |
|---|---|
| macOS | Keychain Access→ Add Root CA to system keychain → Trust setting "Always Trust" |
| Ubuntu/Debian | /usr/local/share/ca-certificates/after copyingsudo update-ca-certificates |
| RHEL/CentOS | /etc/pki/ca-trust/source/anchors/after copyingsudo update-ca-trust |
6. Security/Operational Considerations
6.1 Private Key Protection
- The provided CA private key isKubernetes Secretis saved, and in the RBIProxy Podread-only volumeis mounted.
- Secret access rights are managed by the namespace administrator.minimizeIt is possible.
- If necessary, KMS/HSM integration can be reviewed separately.
6.2 Audit Log
Current operation
- RBIProxy issues dynamically generated leaf certificates.Individual issuance history is not logged separately.(Performance consideration).
- However, logs of the following categories will be recorded.
- Access Log: External domain accessed by the user (CONNECT log)
- CA Load Event: Pod startup CA private key load success/failure
- Change Secret: Kubernetes Audit Log (Cluster Level)
In cases with strict audit requirements
If there are separate audit requirements such as recording the serial number, issuance time, target domain, etc. of the issued leaf certificate, through the person in charge of constructionSeparate consultationPlease request.
6.3 Certificate Replacement (Rollover)
- CA expirationat least 90 days in advanceNew issuance and delivery are required.
- Replacement can be reflected by recreating the Kubernetes Secret + restarting the Pod (involving a brief session interruption).
6.4 Revocation
- The leaf certificate dynamically issued by RBIProxy containsCRL/OCSP URL is not included.(Temporary Issuance Characteristics).
- The CA's own revocation history is recorded in the internal CRL/OCSP system.
6.5 When Changing CA During Operation
- CA replacement isShort session disconnection(Pod restart, usually within 1 minute)
- To minimize the impact on a large number of usersOff-duty hoursChanges are needed.
- Before and Afterat least 30 daysPlease do not discard the previous CA during this period and keep it (for rollback purposes).
7. Checklist (for PKI Manager Confirmation)
Please check the items below before sending.
Common (All Methods)
-
Decision on CA Method: Self-Signed Root CA only or Intermediate CA
-
New issuance of CA for "TLS server certificate issuance"
-
Basic Constraints: CA:TRUE -
Key Usage: keyCertSign, cRLSign(Required) -
Extended Key Usage: serverAuthIncluded (Required) -
Name Constraints Not Set (or Include All Domains Subject to RBI)
-
Key Algorithm = RSA 2048bit or higher
-
SHA-256 Signature
-
Validity period of more than 3 years
Private Key Format
-
private keyPKCS#8 PEMFormat (
-----BEGIN PRIVATE KEY-----) -
private keyplain text(not encrypted)
User PC Deployment
-
Self-Signed Root CA Method: The corresponding Root CA of all target user PCs**"Trusted Root Certification Authority"**Deployment complete
-
Intermediate CA method: Root CA is**"Trusted Root Certification Authority"In, Intermediate CA is"Intermediate Certification Authority"**Completed distribution with __PH_0__ (see section 4.5)
Preparation for Delivery
-
openssl verify -CAfile <Root> <Intermediate>Verification OK (Intermediate method) -
Delivering the Root CA public certificate (for verification) together
-
Security transmission channel (see section 3.2) ready
-
Determination of the Timing for the Destruction of Plaintext Files for Transmission
8. FAQ
Q1. Should I transmit the private key of the Root CA?
A. No.Root CA private key is the highest security asset within the company, so do not share it. DedicatedSelf-Signed Root CAto issue a new one, or under an existing Root CAIntermediate CAPlease issue and deliver a new one.
Q2. Can I use the existing internal web server certificate as is?
A. It is not possible. A general server certificate (end-entity) isCA:FALSEIt has been issued and does not have the authority to sign subordinate certificates. A new CA certificate must be issued.
Q3. Which one should I choose between Self-Signed CA and Intermediate CA?
A. Dedicated Self-Signed Root CA 1 pageWe recommend __PH_0__. The Intermediate CA method has the inconvenience of separately distributing to the user's PC up to Intermediate (see section 4.5). Unless there are special requirements such as existing internal PKI integration audits, the Self-Signed method is simple and reliable.
Q4. Can I issue with an ECDSA key?
A. The current release does not guarantee operation, soRSA above 2048bitPlease issue it.
Q5. Is it possible to have a short validity CA (such as 1 year)?
A. Technically possible, but there is a burden of annual retransmission/re-distribution.more than 3 yearsI need this.
Q6. Can I give a CA restricted by Name Constraints?
A. It is possible, but domains not included in the Name Constraint will trigger a browser warning when accessed through RBIProxy. Please configure it after accurately agreeing on the scope of the domains to be proxied by RBI.
Q7. The private key format is PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) Can I send it as is?
A. Not available.openssl pkcs8 -topk8 -nocryptIt needs to be converted and delivered as a command (see section 3.3).
Q8. I only have a PKCS#12 (.pfx) file. Can I send it as is?
A. It can be delivered. However, since the RBIProxy runtime uses PEM, the person in charge of the implementation will convert it to PEM internally and reflect it. From a security perspective, from the beginning**Separated PEM file (Option A)**It needs to be delivered.
Q9. What happens to the service when the certificate expires?
A. Leaving the expired CA as is may cause a browser warning when creating a new session, which could prevent normal use of the RBI service.Prepare for renewal 90 days before expirationPlease do it.
Q10. Can different CAs be used for different environments (production/staging)?
A. Yes, it is possible. You can create Kubernetes Secrets separately for each environment and mount them separately in each environment's Deployment. By separating the CAs for production/staging, there will be no impact on production even if the staging CA is leaked, so separation is necessary.